1. Field of the Invention
The present invention relates to operating systems, and, more particularly, to an application programming interface (API) for a microkemel.
2. Description of the Related Art
An operating system is an organized collection of programs and data that is specifically designed to manage the resources of computer system and to facilitate the creation of computer programs and control their execution on that system. The use of an operating system obviates the need to provide individual and unique access to the hardware of a computer for each user wishing to run a program on that computer. This simplifies the user""s task of writing of a program because the user is relieved of having to write routines to interface the program to the computer""s hardware. Instead, the user accesses such functionality using standard system calls, which are generally referred to in the aggregate as an application programming interface (API).
A current trend in the design of operating systems is toward smaller operating systems. In particular, operating systems known as microkemels are becoming increasingly prevalent. In certain microkemel operating system architectures, some of the functions normally associated with the operating system, accessed via calls to the operating system""s API, are moved into the user space and executed as user tasks. Microkemels thus tend to be faster and simpler than more complex operating systems.
These advantages are of particular benefit in specialized applications that do not require the range of functionalities provided by a standard operating system. For example, a microkemel-based system is particularly well suited to embedded applications. Embedded applications include information appliances (personal digital assistance (PDAs), network computers, cellular phones, and other such devices), household appliances (e.g., televisions, electronic games, kitchen appliances, and the like), and other such applications. The modularity provided by a microkemel allows only the necessary functions (modules) to be used. Thus, the code required to operate such a device can be kept to a minimum by starting with the microkernel and adding only those modules required for the device""s operation. The simplicity afforded by the use of a microkernel also makes programming such devices simpler.
In real-time applications, particularly in embedded real-time applications, the speed provided by a microkernel-based operating system architecture can be of great benefit. System calls are simplified by making the time taken executing the corresponding kernel code more predictable. This, in turn, simplifies the programming of real-time applications. This is of particular importance when writing software for control operations, such as is often the case in embedded systems.
In one embodiment of the present invention, an operating system architecture is disclosed. The operating system architecture is configured to provide a user space and a kernel space. The operating system architecture comprises a number of tasks, a message, and a microkernel. The tasks are executed in the user space, while the microkernel is executed in the kernel space. The microkernel supports an application programming interface (API) that is configured to support a limited number of directives, the limited number of directives being substantially fewer in number than a number of directives supported by an application programming interface of a traditional operating system. It will be noted that a traditional operating system provides 100 or more directives, and may support 1,000 or more directives. In contrast, a microkernel, according to the present invention, can support fewer than 100 directives through the use of message passing directives and the resulting simplification of such a microkernel. The microkernel is configured to pass the message from a first one of the tasks to a second one of the tasks by virtue of the application programming interface being configured to support message-passing directives. The microkernel is configured to support inter-task communication by virtue of being configured to pass the message from a first one of the tasks to a second one of the tasks. The application programming interface may also support thread manipulation directives and/or data transfer directives. In one aspect of the embodiment, the operating system architecture employs a client/server architecture, in which the first task acts as a client task and the second task acts as a server task.
In another aspect of the embodiment, the microkernel""s API supports only thread manipulation directives, data transfer directives, and message-passing directives. The distinction between a data transfer directive and a message-passing directive is as follows. A message-passing directive supports the passing of a message between tasks using the facilities provided by the operating system. Such a message contains information such as operational parameters, and may also contain relatively small amounts of data. In contrast, a data transfer directive supports the transfer of data to or from a task, and can do so via the operating system or other facilities. This distinction will become more apparent from a detailed reading of the detailed description set forth subsequently. By limiting the directives supported by the API, the microkernel is simplified, making the microkernel""s operation more efficient (e.g., by reducing overhead associated with context switching; the overhead being, for example, the amount of code required to be executed in processing the given directive) and more reliable (e.g., by reducing the amount of code, and so the number of possible programming errors (i.e., xe2x80x9cbugsxe2x80x9d)).
In still another aspect of the embodiment, the directives available through the API may be minimized. In such a scenario, (1) the message-passing directives include a send directive, a receive directive, and a reply directive; (2) the thread manipulation directives include a thread creation directive and a thread destruction directive; and (3) the data transfer directives include a xe2x80x9cfetchxe2x80x9d data directive and a xe2x80x9cstorexe2x80x9d data directive. This maximizes the amount of functionality moved out of the kernel and into the user space.
The foregoing is a summary and thus contains, by necessity, simplifications, generalizations and omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the present invention, as defined solely by the claims, will become apparent in the non-limiting detailed description set forth below.